Snap-in secret server support for protecting secret information

ABSTRACT

A computer system includes a memory to store an application. A processor is configured to start the application, and insert a secret-server hook into the application during start-up. The secret-server hook has instructions to access a secret server with the secret information stored therein. In response to a call being made by the application for the secret information, the secret-server hook has further instructions to intercept the call, and provide the secret information in the secret server to the application based on the intercepted call.

TECHNICAL FIELD

The present disclosure relates to computer systems, and moreparticularly, to protecting secret information on a computer system.

BACKGROUND

Traditionally, personal computer systems within an organization includecombinations of operating systems, applications, and user settings,which are each managed individually by owners or administrators on anongoing basis. Some applications require secret information to access adesired resource, such as a database or a cloud service provider, forexample.

Secret information may be usernames and passwords, database connectionstrings, and service keys, for example. The secret information istypically stored on a computer system in a local storage, such as aconfiguration file or a registry. The configuration file and registryare in plain text (i.e., unencrypted text). This allows an administratorto go in and change the settings when needed, including the secretinformation.

A drawback of storing the secret information in plain text in theconfiguration file or registry is that the secret information may beeasily read by other users having access to the computer system. If auser has malicious intentions, then the secret information may be usedfor illicit purposes. Consequently, there is a need to protect secretinformation on a computer system.

SUMMARY

A computer system includes a memory configured to store an application.A processor is coupled to the memory and is configured to start theapplication, and insert a secret-server hook into the application duringstart-up. The secret-server hook has instructions to access a secretserver with secret information stored therein. In response to theapplication making a call for the secret information, the secret-serverhook intercepts the call, and provides the secret information in thesecret server to the application based on the intercepted call. If thecall being made by the application is not a request for the secretinformation, then the secret-server hook will simply return the resultsof the request.

After the call is made for the secret information, the secret-serverhook may have further instructions to redirect the intercepted call tothe secret server to retrieve the secret information from the secretserver.

Before the call is made for the secret information, the secret-serverhook may have further instructions to retrieve and cache the secretinformation from the secret server. The secret information may be cachedusing a protective storage.

The call being made for the secret information is directed to aconfiguration file or registry that includes blank information insteadof the secret information initially stored therein, and afterinterception of the call, the secret-server hook may have furtherinstructions to search and replace the blank information in theconfiguration file or registry with the secret information from thesecret server, and return an updated configuration file or registry tothe application.

The call being made for the secret information is directed to aconfiguration file or registry, wherein the secret server may beconfigured to store the same configuration file or registry information,and after interception of the call, the secret-server hook may havefurther instructions to return the configuration file or registryinformation from the secret server to the application.

The secret information in the secret server may be stored as name valuepairs, a single encoded string, or a format dependent on the secretserver. The memory and the processor may be in a virtual machine. Theresource being accessed by the application may be external the computersystem.

Another aspect is directed to a method for operating the computer systemas described above. The method includes storing in memory anapplication. A processor is coupled to the memory and is operated tostart the application, and insert a secret-server hook into theapplication during start-up. The secret-server hook has instructions toaccess a secret server with the secret information stored therein. Inresponse to a call being made by the application for the secretinformation, the secret-server hook intercepts the call, and providesthe secret information in the secret server to the application based onthe intercepted call. If the call being made by the application is not arequest for the secret information, then the secret-server hook willsimply return the results of the request.

Yet another aspect is directed to a computing system comprising thesecret server and the computer system as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a network environment ofcomputing devices in which various aspects of the disclosure may beimplemented.

FIG. 2 is a schematic block diagram of a computing device useful forpracticing an embodiment of the client machines or the remote machinesillustrated in FIG. 1 .

FIG. 3 is a schematic block diagram of a cloud computing environment inwhich various aspects of the disclosure may be implemented.

FIG. 4 is a schematic block diagram of desktop, mobile and web baseddevices operating a workspace app in which various aspects of thedisclosure may be implemented.

FIG. 5 is a schematic block diagram of a workspace network environmentof computing devices in which various aspects of the disclosure may beimplemented.

FIG. 6 is a schematic block diagram of a computer system with a secretserver snap-in hook in which various aspects of the disclosure may beimplemented.

FIG. 7 is a schematic block diagram of the computer system illustratedin FIG. 6 without the secret server snap-in hook.

FIG. 8 is a sequence diagram illustrating injection of the secret serversnap-in hook into an application on the computer system illustrated inFIG. 6 .

FIG. 9 is an example list of DLLs that are to be loaded for anapplication operating on the computer system illustrated in FIG. 6 .

FIG. 10 is a process load flow diagram for the secret server snap-inhook operating on the computer system illustrated in FIG. 6 .

FIG. 11 is an initialization flow diagram for the secret server snap-inhook loaded in FIG. 10 .

FIG. 12 is a file configuration request flow diagram using the secretserver snap-in hook loaded in FIG. 10 .

FIG. 13 is a registry configuration request flow diagram using thesecret server snap-in hook loaded in FIG. 10 .

FIG. 14 provides a list of DLLs and corresponding API calls that are tobe hooked for an application on the computer system illustrated in FIG.6 .

FIG. 15 provides instructions for the configuration necessary for thesecret server snap-in to determine the requests to be hooked and theconfiguration necessary to access the secret server for an applicationoperating on the computer system illustrated in FIG. 6 .

FIG. 16 is a simplified flow diagram for the secret server snap-in hookon the computer system illustrated in FIG. 6 .

FIG. 17 is a flowchart illustrating a method for operating the computersystem illustrated in FIG. 6 .

DETAILED DESCRIPTION

The present description is made with reference to the accompanyingdrawings, in which exemplary embodiments are shown. However, manydifferent embodiments may be used, and thus the description should notbe construed as limited to the particular embodiments set forth herein.Rather, these embodiments are provided so that this disclosure will bethorough and complete. Like numbers refer to like elements throughout,and prime notation is used to indicate similar elements in differentembodiments.

Security is a priority in organizations to protect secret information incomputer systems. Local storage, such as configuration files andregistries stored in a persistent memory, are often used to store thesecret information needed by applications running on the computersystems. The configuration files and registries are in plain text. Thisallows anyone accessing the computer systems to read the secretinformation.

One approach to protect the secret information is to keep theconfiguration files and registries in locked down repositories or fileshares. Another approach is to keep the secret information in a secretserver, such as a Thycotic Secret Server, for example. However, theseapproaches require modifications to the application code to direct wherethe secret information is being kept. This is a time consuming and laborintensive process, particularly when dealing with a large quantity ofapplications, which typically include legacy applications.

The techniques and teachings of the present disclosure provide theability for a computer system to retrieve the secret information from asecret server without having to change the application code. Instead,the secret information normally stored as plain or unencrypted text in aconfiguration file or registry in the computer system is replaced withblank information.

A secret server snap-in hook is loaded into the application atapplication start-up. The secret server snap-in hook intercepts allconfiguration file and registry calls made by the application, anddetermines when one of the calls is for secret information. If the callis for secret information, then the call is intercepted and redirectedby the secret server snap-in hook to the secret server to retrieve thesecret information. If the call is not for secret information, then thesecret server snap-in hook allows the call to pass to the configurationfile or registry so that the contents therein are returned to theapplication.

Referring initially to FIG. 1 , a non-limiting network environment 10 inwhich various aspects of the disclosure may be implemented includes oneor more client machines 12A-12N, one or more remote machines 16A-16N,one or more networks 14, 14′, and one or more appliances 18 installedwithin the computing environment 10. The client machines 12A-12Ncommunicate with the remote machines 16A-16N via the networks 14, 14′.

In some embodiments, the client machines 12A-12N communicate with theremote machines 16A-16N via an intermediary appliance 18. Theillustrated appliance 18 is positioned between the networks 14, 14′ andmay also be referred to as a network interface or gateway. In someembodiments, the appliance 18 may operate as an application deliverycontroller (ADC) to provide clients with access to business applicationsand other data deployed in a data center, the cloud, or delivered asSoftware as a Service (SaaS) across a range of client devices, and/orprovide other functionality such as load balancing, etc. In someembodiments, multiple appliances 18 may be used, and the appliance(s) 18may be deployed as part of the network 14 and/or 14′.

The client machines 12A-12N may be generally referred to as clientmachines 12, local machines 12, clients 12, client nodes 12, clientcomputers 12, client devices 12, computing devices 12, endpoints 12, orendpoint nodes 12. The remote machines 16A-16N may be generally referredto as servers 16 or a server farm 16. In some embodiments, a clientdevice 12 may have the capacity to function as both a client nodeseeking access to resources provided by a server 16 and as a server 16providing access to hosted resources for other client devices 12A-12N.The networks 14, 14′ may be generally referred to as a network 14. Thenetworks 14 may be configured in any combination of wired and wirelessnetworks.

A server 16 may be any server type such as, for example: a file server;an application server; a web server; a proxy server; an appliance; anetwork appliance; a gateway; an application gateway; a gateway server;a virtualization server; a deployment server; a Secure Sockets LayerVirtual Private Network (SSL VPN) server; a firewall; a web server; aserver executing an active directory; a cloud server; or a serverexecuting an application acceleration program that provides firewallfunctionality, application functionality, or load balancingfunctionality.

A server 16 may execute, operate or otherwise provide an applicationthat may be any one of the following: software; a program; executableinstructions; a virtual machine; a hypervisor; a web browser; aweb-based client; a client-server application; a thin-client computingclient; an ActiveX control; a Java applet; software related to voiceover internet protocol (VoIP) communications like a soft IP telephone;an application for streaming video and/or audio; an application forfacilitating real-time-data communications; a HTTP client; a FTP client;an Oscar client; a Telnet client; or any other set of executableinstructions.

In some embodiments, a server 16 may execute a remote presentationservices program or other program that uses a thin-client or aremote-display protocol to capture display output generated by anapplication executing on a server 16 and transmit the applicationdisplay output to a client device 12.

In yet other embodiments, a server 16 may execute a virtual machineproviding, to a user of a client device 12, access to a computingenvironment. The client device 12 may be a virtual machine. The virtualmachine may be managed by, for example, a hypervisor, a virtual machinemanager (VMM), or any other hardware virtualization technique within theserver 16.

In some embodiments, the network 14 may be: a local-area network (LAN);a metropolitan area network (MAN); a wide area network (WAN); a primarypublic network 14; and a primary private network 14. Additionalembodiments may include a network 14 of mobile telephone networks thatuse various protocols to communicate among mobile devices. For shortrange communications within a wireless local-area network (WLAN), theprotocols may include 802.11, Bluetooth, and Near Field Communication(NFC).

FIG. 2 depicts a block diagram of a computing device 20 useful forpracticing an embodiment of client devices 12, appliances 18 and/orservers 16. The computing device 20 includes one or more processors 22,volatile memory 24 (e.g., random access memory (RAM)), non-volatilememory 30, user interface (UI) 38, one or more communications interfaces26, and a communications bus 48.

The non-volatile memory 30 may include: one or more hard disk drives(HDDs) or other magnetic or optical storage media; one or more solidstate drives (SSDs), such as a flash drive or other solid-state storagemedia; one or more hybrid magnetic and solid-state drives; and/or one ormore virtual storage volumes, such as a cloud storage, or a combinationof such physical storage volumes and virtual storage volumes or arraysthereof.

The user interface 38 may include a graphical user interface (GUI) 40(e.g., a touchscreen, a display, etc.) and one or more input/output(I/O) devices 42 (e.g., a mouse, a keyboard, a microphone, one or morespeakers, one or more cameras, one or more biometric scanners, one ormore environmental sensors, and one or more accelerometers, etc.).

The non-volatile memory 30 stores an operating system 32, one or moreapplications 34, and data 36 such that, for example, computerinstructions of the operating system 32 and/or the applications 34 areexecuted by processor(s) 22 out of the volatile memory 24. In someembodiments, the volatile memory 24 may include one or more types of RAMand/or a cache memory that may offer a faster response time than a mainmemory. Data may be entered using an input device of the GUI 40 orreceived from the I/O device(s) 42. Various elements of the computer 20may communicate via the communications bus 48.

The illustrated computing device 20 is shown merely as an example clientdevice or server, and may be implemented by any computing or processingenvironment with any type of machine or set of machines that may havesuitable hardware and/or software capable of operating as describedherein.

The processor(s) 22 may be implemented by one or more programmableprocessors to execute one or more executable instructions, such as acomputer program, to perform the functions of the system. As usedherein, the term “processor” describes circuitry that performs afunction, an operation, or a sequence of operations. The function,operation, or sequence of operations may be hard coded into thecircuitry or soft coded by way of instructions held in a memory deviceand executed by the circuitry. A processor may perform the function,operation, or sequence of operations using digital values and/or usinganalog signals.

In some embodiments, the processor can be embodied in one or moreapplication specific integrated circuits (ASICs), microprocessors,digital signal processors (DSPs), graphics processing units (GPUs),microcontrollers, field programmable gate arrays (FPGAs), programmablelogic arrays (PLAs), multi-core processors, or general-purpose computerswith associated memory.

The processor 22 may be analog, digital or mixed-signal. In someembodiments, the processor 22 may be one or more physical processors, orone or more virtual (e.g., remotely located or cloud) processors. Aprocessor including multiple processor cores and/or multiple processorsmay provide functionality for parallel, simultaneous execution ofinstructions or for parallel, simultaneous execution of one instructionon more than one piece of data.

The communications interfaces 26 may include one or more interfaces toenable the computing device 20 to access a computer network such as aLocal Area Network (LAN), a Wide Area Network (WAN), a Personal AreaNetwork (PAN), or the Internet through a variety of wired and/orwireless connections, including cellular connections.

In described embodiments, the computing device 20 may execute anapplication on behalf of a user of a client device. For example, thecomputing device 20 may execute one or more virtual machines managed bya hypervisor. Each virtual machine may provide an execution sessionwithin which applications execute on behalf of a user or a clientdevice, such as a hosted desktop session. The computing device 20 mayalso execute a terminal services session to provide a hosted desktopenvironment. The computing device 20 may provide access to a remotecomputing environment including one or more applications, one or moredesktop applications, and one or more desktop sessions in which one ormore applications may execute.

An example virtualization server 16 may be implemented using CitrixHypervisor provided by Citrix Systems, Inc., of Fort Lauderdale, Fla.(“Citrix Systems”). Virtual app and desktop sessions may further beprovided by Citrix Virtual Apps and Desktops (CVAD), also from CitrixSystems. Citrix Virtual Apps and Desktops is an applicationvirtualization solution that enhances productivity with universal accessto virtual sessions including virtual app, desktop, and data sessionsfrom any device, plus the option to implement a scalable VDI solution.Virtual sessions may further include Software as a Service (SaaS) andDesktop as a Service (DaaS) sessions, for example.

Referring to FIG. 3 , a cloud computing environment 50 is depicted,which may also be referred to as a cloud environment, cloud computing orcloud network. The cloud computing environment 50 can provide thedelivery of shared computing services and/or resources to multiple usersor tenants. For example, the shared resources and services can include,but are not limited to, networks, network bandwidth, servers,processing, memory, storage, applications, virtual machines, databases,software, hardware, analytics, and intelligence.

In the cloud computing environment 50, one or more clients 52A-52C (suchas those described above) are in communication with a cloud network 54.The cloud network 54 may include backend platforms, e.g., servers,storage, server farms or data centers. The users or clients 52A-52C cancorrespond to a single organization/tenant or multipleorganizations/tenants. More particularly, in one example implementationthe cloud computing environment 50 may provide a private cloud serving asingle organization (e.g., enterprise cloud). In another example, thecloud computing environment 50 may provide a community or public cloudserving multiple organizations/tenants. In still further embodiments,the cloud computing environment 50 may provide a hybrid cloud that is acombination of a public cloud and a private cloud. Public clouds mayinclude public servers that are maintained by third parties to theclients 52A-52C or the enterprise/tenant. The servers may be locatedoff-site in remote geographical locations or otherwise.

The cloud computing environment 50 can provide resource pooling to servemultiple users via clients 52A-52C through a multi-tenant environment ormulti-tenant model with different physical and virtual resourcesdynamically assigned and reassigned responsive to different demandswithin the respective environment. The multi-tenant environment caninclude a system or architecture that can provide a single instance ofsoftware, an application or a software application to serve multipleusers. In some embodiments, the cloud computing environment 50 canprovide on-demand self-service to unilaterally provision computingcapabilities (e.g., server time, network storage) across a network formultiple clients 52A-52C. The cloud computing environment 50 can providean elasticity to dynamically scale out or scale in responsive todifferent demands from one or more clients 52. In some embodiments, thecomputing environment 50 can include or provide monitoring services tomonitor, control and/or generate reports corresponding to the providedshared services and resources.

In some embodiments, the cloud computing environment 50 may providecloud-based delivery of different types of cloud computing services,such as Software as a service (SaaS) 56, Platform as a Service (PaaS)58, Infrastructure as a Service (IaaS) 60, and Desktop as a Service(DaaS) 62, for example. IaaS may refer to a user renting the use ofinfrastructure resources that are needed during a specified time period.IaaS providers may offer storage, networking, servers or virtualizationresources from large pools, allowing the users to quickly scale up byaccessing more resources as needed. Examples of IaaS include AMAZON WEBSERVICES provided by Amazon.com, Inc., of Seattle, Wash., RACKSPACECLOUD provided by Rackspace US, Inc., of San Antonio, Tex., GoogleCompute Engine provided by Google Inc. of Mountain View, Calif., orRIGHTSCALE provided by RightScale, Inc., of Santa Barbara, Calif.

PaaS providers may offer functionality provided by IaaS, including,e.g., storage, networking, servers or virtualization, as well asadditional resources such as, e.g., the operating system, middleware, orruntime resources. Examples of PaaS include WINDOWS AZURE provided byMicrosoft Corporation of Redmond, Wash., Google App Engine provided byGoogle Inc., and HEROKU provided by Heroku, Inc. of San Francisco,Calif.

SaaS providers may offer the resources that PaaS provides, includingstorage, networking, servers, virtualization, operating system,middleware, or runtime resources. In some embodiments, SaaS providersmay offer additional resources including, e.g., data and applicationresources. Examples of SaaS include GOOGLE APPS provided by Google Inc.,SALESFORCE provided by Salesforce.com Inc. of San Francisco, Calif., orOFFICE 365 provided by Microsoft Corporation. Examples of SaaS may alsoinclude data storage providers, e.g. DROPBOX provided by Dropbox, Inc.of San Francisco, Calif., Microsoft ONEDRIVE provided by MicrosoftCorporation, Google Drive provided by Google Inc., or Apple ICLOUDprovided by Apple Inc. of Cupertino, Calif.

Similar to SaaS, DaaS (which is also known as hosted desktop services)is a form of virtual desktop infrastructure (VDI) in which virtualdesktop sessions are typically delivered as a cloud service along withthe apps used on the virtual desktop. Citrix Cloud is one example of aDaaS delivery platform. DaaS delivery platforms may be hosted on apublic cloud computing infrastructure such as AZURE CLOUD from MicrosoftCorporation of Redmond, Wash. (herein “Azure”), or AMAZON WEB SERVICESprovided by Amazon.com, Inc., of Seattle, Wash. (herein “AWS”), forexample. In the case of Citrix Cloud, Citrix Workspace app may be usedas a single-entry point for bringing apps, files and desktops together(whether on-premises or in the cloud) to deliver a unified experience.

The unified experience provided by the Citrix Workspace app will now bediscussed in greater detail with reference to FIG. 4 . The CitrixWorkspace app will be generally referred to herein as the workspace app70. The workspace app 70 is how a user gets access to their workspaceresources, one category of which is applications. These applications canbe SaaS apps, web apps or virtual apps. The workspace app 70 also givesusers access to their desktops, which may be a local desktop or avirtual desktop. Further, the workspace app 70 gives users access totheir files and data, which may be stored in numerous repositories. Thefiles and data may be hosted on Citrix ShareFile, hosted on anon-premises network file server, or hosted in some other cloud storageprovider, such as Microsoft OneDrive or Google Drive Box, for example.

To provide a unified experience, all of the resources a user requiresmay be located and accessible from the workspace app 70. The workspaceapp 70 is provided in different versions. One version of the workspaceapp 70 is an installed application for desktops 72, which may be basedon Windows, Mac or Linux platforms. A second version of the workspaceapp 70 is an installed application for mobile devices 74, which may bebased on iOS or Android platforms. A third version of the workspace app70 uses a hypertext markup language (HTML) browser to provide a useraccess to their workspace environment. The web version of the workspaceapp 70 is used when a user does not want to install the workspace app ordoes not have the rights to install the workspace app, such as whenoperating a public kiosk 76.

Each of these different versions of the workspace app 70 mayadvantageously provide the same user experience. This advantageouslyallows a user to move from client device 72 to client device 74 toclient device 76 in different platforms and still receive the same userexperience for their workspace. The client devices 72, 74 and 76 arereferred to as endpoints.

As noted above, the workspace app 70 supports Windows, Mac, Linux, iOS,and Android platforms as well as platforms with an HTML browser (HTML5).The workspace app 70 incorporates multiple engines 80-90 allowing usersaccess to numerous types of app and data resources. Each engine 80-90optimizes the user experience for a particular resource. Each engine80-90 also provides an organization or enterprise with insights intouser activities and potential security threats.

An embedded browser engine 80 keeps SaaS and web apps contained withinthe workspace app 70 instead of launching them on a locally installedand unmanaged browser. With the embedded browser, the workspace app 70is able to intercept user-selected hyperlinks in SaaS and web apps andrequest a risk analysis before approving, denying, or isolating access.

A high definition experience (HDX) engine 82 establishes connections tovirtual browsers, virtual apps and desktop sessions running on eitherWindows or Linux operating systems. With the HDX engine 82, Windows andLinux resources run remotely, while the display remains local, on theendpoint. To provide the best possible user experience, the HDX engine82 utilizes different virtual channels to adapt to changing networkconditions and application requirements. To overcome high-latency orhigh-packet loss networks, the HDX engine 82 automatically implementsoptimized transport protocols and greater compression algorithms. Eachalgorithm is optimized for a certain type of display, such as video,images, or text. The HDX engine 82 identifies these types of resourcesin an application and applies the most appropriate algorithm to thatsection of the screen.

For many users, a workspace centers on data. A content collaborationengine 84 allows users to integrate all data into the workspace, whetherthat data lives on-premises or in the cloud. The content collaborationengine 84 allows administrators and users to create a set of connectorsto corporate and user-specific data storage locations. This can includeOneDrive, Dropbox, and on-premises network file shares, for example.Users can maintain files in multiple repositories and allow theworkspace app 70 to consolidate them into a single, personalizedlibrary.

A networking engine 86 identifies whether or not an endpoint or an appon the endpoint requires network connectivity to a secured backendresource. The networking engine 86 can automatically establish a fullVPN tunnel for the entire endpoint device, or it can create anapp-specific p-VPN connection. A p-VPN defines what backend resources anapplication and an endpoint device can access, thus protecting thebackend infrastructure. In many instances, certain user activitiesbenefit from unique network-based optimizations. If the user requests afile copy, the workspace app 70 can automatically utilize multiplenetwork connections simultaneously to complete the activity faster. Ifthe user initiates a VoIP call, the workspace app 70 improves itsquality by duplicating the call across multiple network connections. Thenetworking engine 86 uses only the packets that arrive first.

An analytics engine 88 reports on the user's device, location andbehavior, where cloud-based services identify any potential anomaliesthat might be the result of a stolen device, a hacked identity or a userwho is preparing to leave the company. The information gathered by theanalytics engine 88 protects company assets by automaticallyimplementing counter-measures.

A management engine 90 keeps the workspace app 70 current. This not onlyprovides users with the latest capabilities, but also includes extrasecurity enhancements. The workspace app 70 includes an auto-updateservice that routinely checks and automatically deploys updates based oncustomizable policies.

Referring now to FIG. 5 , a workspace network environment 100 providinga unified experience to a user based on the workspace app 70 will bediscussed. The desktop, mobile and web versions of the workspace app 70all communicate with the workspace experience service 102 running withinthe Citrix Cloud 104. The workspace experience service 102 then pulls inall the different resource feeds via a resource feed micro-service 108.That is, all the different resources from other services running in theCitrix Cloud 104 are pulled in by the resource feed micro-service 108.The different services may include a virtual apps and desktop service110, a secure browser service 112, an endpoint management service 114, acontent collaboration service 116, and an access control service 118.Any service that an organization or enterprise subscribes to areautomatically pulled into the workspace experience service 102 anddelivered to the user's workspace app 70.

In addition to cloud feeds 120, the resource feed micro-service 108 canpull in on-premises feeds 122. A cloud connector 124 is used to providevirtual apps and desktop deployments that are running in an on-premisesdata center. Desktop virtualization may be provided by Citrix virtualapps and desktops 126, Microsoft RDS 128 or VMware Horizon 130, forexample. In addition to cloud feeds 120 and on-premises feeds 122,device feeds 132 from Internet of Thing (IoT) devices 134, for example,may be pulled in by the resource feed micro-service 108. Siteaggregation is used to tie the different resources into the user'soverall workspace experience.

The cloud feeds 120, on-premises feeds 122 and device feeds 132 eachprovides the user's workspace experience with a different and uniquetype of application. The workspace experience can support local apps,SaaS apps, virtual apps, and desktops browser apps, as well as storageapps. As the feeds continue to increase and expand, the workspaceexperience is able to include additional resources in the user's overallworkspace. This means a user will be able to get to every singleapplication that they need access to.

Still referring to the workspace network environment 20, a series ofevents will be described on how a unified experience is provided to auser. The unified experience starts with the user using the workspaceapp 70 to connect to the workspace experience service 102 running withinthe Citrix Cloud 104, and presenting their identity (event 1). Theidentity includes a user name and password, for example.

The workspace experience service 102 forwards the user's identity to anidentity micro-service 140 within the Citrix Cloud 104 (event 2). Theidentity micro-service 140 authenticates the user to the correctidentity provider 142 (event 3) based on the organization's workspaceconfiguration. Authentication may be based on an on-premises activedirectory 144 that requires the deployment of a cloud connector 146.Authentication may also be based on Azure Active Directory 148 or even athird party identity provider 150, such as Citrix ADC or Okta, forexample.

Once authorized, the workspace experience service 102 requests a list ofauthorized resources (event 4) from the resource feed micro-service 108.For each configured resource feed 106, the resource feed micro-service108 requests an identity token (event 5) from the single-signmicro-service 152.

The resource feed specific identity token is passed to each resource'spoint of authentication (event 6). On-premises resources 122 arecontacted through the Citrix Cloud Connector 124. Each resource feed 106replies with a list of resources authorized for the respective identity(event 7).

The resource feed micro-service 108 aggregates all items from thedifferent resource feeds 106 and forwards (event 8) to the workspaceexperience service 102. The user selects a resource from the workspaceexperience service 102 (event 9).

The workspace experience service 102 forwards the request to theresource feed micro-service 108 (event 10). The resource feedmicro-service 108 requests an identity token from the single sign-onmicro-service 152 (event 11). The user's identity token is sent to theworkspace experience service 102 (event 12) where a launch ticket isgenerated and sent to the user.

The user initiates a secure session to a gateway service 160 andpresents the launch ticket (event 13). The gateway service 160 initiatesa secure session to the appropriate resource feed 106 and presents theidentity token to seamlessly authenticate the user (event 14). Once thesession initializes, the user is able to utilize the resource (event15). Having an entire workspace delivered through a single access pointor application advantageously improves productivity and streamlinescommon workflows for the user.

Referring now to FIG. 6 , the illustrated computer system 300 providesthe ability for applications 302, 312 to retrieve secret information308(a)-308(b), 318(a)-318(b) from a secret server 340 via a secretserver snap-in hook 304 instead of from local storage 306, 316 on thecomputer system 300. The secret information 308, 318 normally stored inthe local storage 306, 308 has been replaced with blank information. Inother words, the secret information has been removed from the localstorage 306, 308 and is to be retrieved from the secret server 340 whena call is made by the applications 302, 312.

The computer system 300 may be a virtual machine (on-premises orcloud-based) or a physical machine. For Windows based operating systems,the local storage 306, 316 provides configuration files and registries.The computer system 300 is not limited to a Windows based operatingsystem, as other types of operating systems may be used, such as Linux,for example.

As will be explained in greater detail below, the secret server snap-inhook 304 is inserted into the applications 302, 312 when theapplications are launched or started-up by a processor within thecomputer system 300. The term snap-in refers to injecting or attachingsoftware code to the applications 302, 312 without changing theunderlying code for the applications 302, 312. The secret server snap-inhook 304 basically sits in the middle and intercepts calls for thesecret information and redirects the intercepted calls to the secretserver 340.

The secret server snap-in hook 304 intercepts all calls (e.g.,configuration file and registry calls) made by the applications 302,312, and determines when one of the calls is for secret information. Ifthe call is for secret information, then the call is intercepted andredirected by the secret server snap-in hook 304 to the secret server340 in order to retrieve the secret information 308(a)-308(b),318(a)-318(b) requested by the applications 302, 312. If the call is nota request for secret information, then the secret server snap-in hook304 allows the call to pass to the configuration file or registry in thelocal storage 306, 316 so that the contents therein are returned to theapplications 302, 312.

Oftentimes applications require secret information to access a desiredresource. As an example, App 1 302 is to access a database 360 and App 2312 is to access a cloud service provider 370. Access to the resource isgranted using the secret information. The secret information may beusernames and passwords, database connection strings, and service keys,for example. For comparison purposes, the computer system 300 in FIG. 7does not use the secret server snap-in hook 304 to retrieve the secretinformation 308, 318 from a secret server 340.

Instead, App 1 and App 2 in FIG. 7 retrieve the secret information 308,318 from the local storage 306, 316 on the computer system 300. Thesecret information 308, 318 is stored in plain or unencrypted textwithin the local storage 306, 316. Storing the secret information 308,318 in plain or unencrypted text allows an administrator to go into thecomputer system 300 and make changes when needed. A disadvantage ofstoring the secret information 308, 318 in plain text is that anyoneelse accessing the computer system 300 will be able to read the secretinformation. For example, a hacker may access the computer system 300 tosteal the secret information to use for malicious intent.

One approach to protect the secret information 308, 318 in the localstorage 306, 316 is to use encryption. However, App 1 302 and App 2 312are both expected to retrieve the secret information 308, 318 in plainor unencrypted text. If the secret information 308, 318 was encrypted,the code in App 1 and App 2 would need to be modified to be able to readthe encrypted secret information 308, 318. Making changes to applicationcode is a time consuming and labor intensive process, particularly whendealing with a large quantity of applications, which typically includelegacy applications.

Referring back to FIG. 6 , the secret server snap-in hook 304 allows thesecret information 308(a)-308(b), 318(a)-318(b) needed by App 1 302 andApp 2 312 to be retrieved from a secret server 340 instead of from thelocal storage 306, 316. The use of a secret server 340 advantageouslysafe guards the secret information needed by the computer system 300.The secret server 340 is a system that enables secure storage of data.Configuration data is typically name/value pairs. As an alternative toname/value pairs, the secret server 340 can store a single encodedstring, certificates, and other formats dependent on the secret server340. The secret server 340 may be cloud based to provide a unifiedinterface to the secret information, while providing tight accesscontrol and recording a detailed audit log. HashiCorp Vault and AzureKey Vault are example secret servers 340. Another example secret server340 is a Thycotic Secret Server.

In response to a call being made for the secret information308(a)-308(b), 318(a)-318(b), the secret-server snap-in hook 304 isconfigured to intercept the call, determine if the contents should beobtained from the secret server 340, and if so, provide the secretinformation 308(a)-308(b), 318(a)-318(b) in the secret server 340 to theapplication 302, 312 making the call. The secret information308(a)-308(b), 318(a)-318(b) may be retrieved after the call is made(i.e., without caching) or before the call is made (i.e., with caching).

Without caching, the secret-server snap-in hook 304 intercepts the call,making a request to the secret server 340 to retrieve the secretinformation 308(a)-308(b), 318(a)-318(b) when needed from the secretserver 340. This is performed in real-time.

With caching, the secret-server snap-in hook 304 retrieves and cachesthe secret information 308(a)-308(b), 318(a)-318(b) from the secretserver 340 when the secret-server snap-in hook 304 is injected into theapplication 302, 312. The cached secret information 308(a)-308(b),318(a)-318(b) is under a protective storage mechanism, such as acredential manager by Windows, that is secure and utilizes the embeddedcapabilities of the physical hardware of the computer system 300.

Alternatively, the protective storage mechanism may encrypt the secretinformation 308(a)-308(b), 318(a)-318(b) when stored on the computersystem 300 and decrypt when needed by the application 302, 312.

The secret server 340 has a secret 1 key/value 308(a) and a secret 2key/value 308(b) associated with App 1 302. The name value pair forsecret 1 key/value 308(a) may have “username” as the name with thecorresponding value being the actual username of the user. The namevalue pair for secret 2 key/value 308(b) may have “password” as the namewith the corresponding value being the actual password of the user.Similarly, the secret server 340 has a secret 1 key/value 318(b) and asecret 2 key/value 318(b) associated with App 2 312. User/password arenot to be limiting as any name value pair required by the applications302, 312 which has sensitive data for the value may be used.

Referring now to FIG. 8 , a sequence diagram 400 illustrates injectionof the secret server snap-in hook 304 into an application 302 by adriver 430. As will be discussed below, the driver 430 is installed onthe operating system and will be loaded into all processes (e.g.,application 302) in order to support kernel asynchronous procedure calls(KAPC) within the application 302. Injection of the secret serversnap-in hook 304 is piggybacked on an asynchronous procedure call madeby the application 302. The driver 430 may also be referred to as a KAPCdriver or a universal driver.

The operating system of the computer system 300 has a user mode 410 anda kernel mode 420. The memory for the user mode 410 helps the operatingsystem in running applications, such as App 1 302 and App 2 312. Thememory for the kernel model 420 is required when the computer system 300boots and the operating system is loaded. Some of the privilegedinstructions work in kernel mode only.

An application, such as App 1 302, typically starts in the user mode410. This corresponds to box 450. Injection of the secret server snap-inhook 304 is done by the KAPC driver 430 running in the kernel mode 420.The KAPC driver 430 includes a monitor create/destroy process module 432that is notified when App 1 302 is started-up, which corresponds to line(1).

The KAPC driver 430 is a custom universal driver as provided by CitrixSystems, for example, that is used to inject the necessary hooks intoApp 1 302 so that the application will operate differently than theapplication would normally operate. The KAPC driver 430 is configured toinject the secret server snap-in hook 304 into any application thatutilizes the functions identified in the configuration (see FIG. 14 ).Once the secret server snap-in hook 304 has been injected, the KAPCdriver 430 is dormant until another create/destroy process is detected.In otherwords, the KAPC driver 430 is event driven, and is notified bythe operating system when a process is created/destroyed.

The KAPC driver 430 includes a monitor load image module 434. Thismodule 434 is monitoring the usage of a particular DLL (dynamic linklibrary) that the App 1 302 is loading. A DLL file contains a library offunctions and other information that can be accessed by App 1 302. WhenApp 1 302 is launched, links to the necessary DLL files are created. Inthis case, the KAPC driver 430 is monitoring for when a kernel 32 DLL452 is loaded, which corresponds to line (2).

As will be discussed below in reference to FIG. 14 , the monitoractually watches for any of the DLL's identified by this config, and ifthere is a match, it will inject the hook Dll to replace the functioncall 524 in the DLL 522 with a call to the hook-dll function 526 andkeep track of the original function 528.

The KAPC driver 430 includes a KAPC (kernel asynchronous procedure call)loader routine code module 436. This module 436 in the KAPC driver 430is mapped to a KAPC loader routine module 454 in the memory of the usermode 410, which corresponds to line (3). The KAPC loader routine module454 already exists in a Windows based operating system, and is beingused to perform the injection. In other words, the injection initiatedby the KAPC driver 430 is based off of a KAPC operation.

The KAPC driver 430 includes a queue user mode APC (application programcommand) module 438, which is associated with the KAPC loader routinemodule 454 in the user mode 410. The KAPC loader routine module 454 isthen associated with an APC queue module 456 in the user mode 410. Thisjoint association corresponds to lines (4). The KAPC loader routinemodule 454 is only used during the load process to establish the hook.When the application 302 calls the API, the application 302 thinks it iscalling Kernel32.DLL→CreateFileA but the KAPC driver 430 previouslyreplaced that with a pointer to HookedCreateFileA so it actually callsHookedCreateFileA directly (see FIG. 14 ). Since the API call isasynchronous, the KAPC loader routine module 454 queues the API call inthe APC queue module 456 until ready for execution.

When the asynchronous call (e.g., initialize memory) in the APC queuemodule 456 is ready for execution, then it is dequeued from the APCqueue module 456 and returned to the kernel 32 DLL 452 at line (5). Atthis time, the driver 430 injects into the application a snap-in hookDLL 458 at line (6) and the secret server snap-in hook DLL 304 at line(7) into the user mode 410. The snap-in hook DLL 458 and the secretserver snap-in hook DLL 304 are piggybacked on top of the asynchronouscall being made by the kernel 32 DLL 452.

The snap-in hook DLL 458 is used to intercept and redirect an API callbeing made by the application for the secret information 308, 318 in thelocal storage 306, 316. The secret server snap-in hook DLL 304 providesthe location within the secret server 340 to retrieve the secretinformation 308(a)-308(b) that will be returned to the App 1 302 as ifthe initial API call was made to the local storage 306. In other words,the App 1 302 is not aware that the API call for the secret information308 is being intercepted and redirected to the secret server 340.

Once the API call has been executed by the kernel 32 DLL module 452,then the snap-in hook 458 and the secret server snap-in hook 304 areloaded into the user mode memory 410. The snap-in hook 458 and thesecret server snap-in hook 304 are DLL files. The snap-in hook 458 is tomonitor for API calls requesting secret information in the local storage306, which corresponds to line (6). If a call is requesting secretinformation, then this call is intercepted and redirected to the secretserver snap-in hook 304, which corresponds to line (7). The secretserver snap-in hook 304 then contacts the secret server 340 to retrievethe secret information 308(a)-308(b) being requested by the API call.

The KAPC loader routing module 454 is leveraged during the load processto put the secret server snap-in hook 304 in place. The applications302, 312 are representative of others in the industry, and as such, havea requirement that secrets being consumed by the application will becoming from a file or the Windows registry—at the lowest level. The lowlevel APIs being referenced that will be intercepted include, but arenot limited to, CreateFile( ), OpenFile( ), RegOpenKey( ), SHGetValue().

Intercepting the low level APIs maximizes the number of uses cases thatthe secret server snap-in hook 304 can accommodate. Any file accessed byany process on Windows will, at a low-enough level, go through one ofthe file I/O or Registry I/O API functions. Interception/hooking inuser-mode will suffice a majority of the time. However, in the casewhere a certain process may bypass one of the user-mode APIs mentionedabove (e.g., part of another subsystem or runtime adjacent to Win32,such as UWP), then the kernel-mode API will be hooked instead or inaddition.

Referring to the example list of DLLs 500 in FIG. 9 , these DLLs areloaded when an application, such as App 1 302, is started. Not every DLLis to be hooked. The DLLs that are to be hooked are the ones referencedin the code snippet as illustrated in FIG. 14 . The DLLs that are to behooked include the following: advapi32.dll 502, kernel32.dll 504, andntdll.dll 506.

The secret server snap-in hook 304 is injected in the path of thehighlighted DLLs. For discussion purposes, these DLLs have manyfunctions and the ones defined in FIG. 14 are hooked. For the hookedDLLs, the secret server snap-in hook 304 intercepts API calls for thesecret information and redirects to the secret server 340. If an APIcall from one of the hooked DLLs does not request the secretinformation, then that API call is passed to the local storage 306 onthe computer system 300.

Referring now to FIGS. 10-13 , various flow diagrams illustratingoperation of the secret server snap-in hook 304 will be discussed. Thesecret server snap-in hook 304 will be “hooked” into a given process tointercept calls (via low-level APIs) to retrieve the secret information308(a)-308(b), 318(a)-318(b) from the secret server 340 instead of fromconfiguration files or registries in the local storage 306, 316 on thecomputer system 300.

A process load flow diagram 600 is provided in FIG. 10 , which isloading of the secret server snap-in hook 304 into an application, suchas App 1 302. The driver 430 is notified of a new process event at line602. The new process event may be start-up of App 1 302, for example.

The driver 430 is monitoring the DLL load event looking for a DLL thatmatches any contained in the list illustrated in FIG. 14 . As discussedabove, the driver is monitoring for any DLL identified in FIG. 14 to beloaded. If any DLL identified in the KAPC configuration (see FIG. 14 )is being loaded, then the secret server snap-in hook 304 is injectedinto App 1 302, as represented in box section 606. If kernel 32 DLL 452does not include API calls for the secret information 308 in the localstorage 306, then the secret server snap-in hook 304 is not injectedinto App 1 302, as represented in box section 608. Completion of loadingthe kernel 32 DLL 452 is at line 610.

An initialization flow diagram 620 is provided in FIG. 11 , which isinitialization of the secret server snap-in hook 304. The initializationoccurs when the secret server snap-in hook 304 is loaded. The secretserver snap-in hook 304 includes allocation code for an applicationwriter to change the application configuration when the KAPC driver 430is installed and the secret server snap-in hook 304 configuration fileis created.

The secret server snap-in hook 304 may be configured with cache enabledor with cache not enabled. If the secret information 308 (a)-308 (b),318 (a)-318 (b) is to be cached, as represented in box section 626, thenthe secret server snap-in hook 304 retrieves the secret information308(a)-308(b), 318(a)-318(b) from the secret server 340. If the secretinformation 308 (a)-308 (b), 318 (a)-318 (b) is not to be cached, asrepresented in box section 628, then the secret server snap-in hook 304retrieves the retrieves the secret information 308(a)-308(b),318(a)-318(b) from the secret server 340 when needed.

Caching allows for App 1 302 or App 2 312 to more quickly receive thesecret information 308(a)-308(b), 318(a)-318(b) when requested. Thecached secret information 308(a)-308(b), 318(a)-318(b) is not stored onthe computer system 300 in plain text as done in local storage 306, 316.

The cached secret information 308(a)-308(b), 318(a)-318(b) is storedusing a protective storage mechanism, such as a credential manager. Theprotective storage mechanism may encrypt the secret information308(a)-308(b), 318(a)-318(b) when stored on the computer system 300 anddecrypted when needed by App 1 302 and App 2 312. If the secretinformation 308(a)-308(b), 318(a)-318(b) is cached, then thisinformation is securely persisted at line 630.

A file configuration request flow diagram 640 is provided in FIG. 12 ,which is App 1 302 making an API call to for a configuration file 657 inthe local storage 306. An API call for a configuration item is made byApp 1 302 at line 642. For a system file 659 on the computer system 300,a hook within the DLL designated in FIG. 14 (e.g., Kernel32, AdvApi32,NtDll) routes the API call to the secret server snap-in hook 304 at line644. The secret server snap-in hook 304 is to make the call for theconfiguration file at line 646.

The cache may be enabled, as represented in box section 648. If thecache is enabled, the secret information 308(a)-308(b) is retrieved froma local store on the computer system 300. The secret server snap-in hook304 then receives the original configuration file, and performs a searchand replace for the blank information 308 in the configuration file 657with the cached secret information 308(a)-308(b).

Alternatively, the cache may not be enabled, as represented in boxsection 650. If the cache is not enabled, a basic or an advancedoperation may be performed by the secret server snap-in hook 304.

The basic operation involves the secret server snap-in hook 304retrieving the entire configuration file stored in the secret server340. The entire configuration file includes the secret information308(a)-308(b) as well as non-secret information.

The advanced operation involves the secret server snap-in hook 304retrieving only the secret information 308(a)-308(b) from the secretserver 340. The secret server snap-in hook 304 then receives theoriginal configuration file, and performs a search and replace for theblank information 308 in the configuration file 657 with the cachedsecret information 308(a)-308(b).

The configuration file with the secret information 308(a)-308(b) fromthe secret server 340 is returned at line 652. The request by App 1 302is for a configuration file at line 654, and is retuned to App 1 302 atline 656. A registry configuration request flow diagram 660 is providedin FIG. 13 , which is App 1 302 making an API call for registryinformation 677. An API call for a configuration item is made by App 1302 at line 662. For a system registry 679 on the computer system 300, ahook is associated with a DLL (e.g. AdvApi32.dll or NT.dll) as definedin FIG. 14 and routes the API call to the secret server snap-in hook 304at line 664. The secret server snap-in hook 304 is to make the call forthe registry at line 666.

The cache may be enabled, as represented in box section 668. If thecache is enabled, the secret information 308(a)-308(b) is retrieved froma local store on the computer system 300. The secret server snap-in hook304 then receives the original registry information, and performs asearch and replace for the secret information 308 in the registry 677with the cached secret information 308(a)-308(b).

Alternatively, the cache may not be enabled, as represented in boxsection 670. If the cache is not enabled, a basic or an advancedoperation may be performed by the secret server snap-in hook 304.

The basic operation involves the secret server snap-in hook 304retrieving the entire registry section stored in the secret server 340.The entire registry includes the secret information 308(a)-308(b) aswell as non-secret information.

The advanced operation involves the secret server snap-in hook 304retrieving only the secret information 308(a)-308(b) from the secretserver 340. The secret server snap-in hook 304 then receives theoriginal registry information, and performs a search and replace for thesecret information 308 in the registry 677 with the cached secretinformation 308(a)-308(b).

The registry information with the secret information 308(a)-308(b) fromthe secret server 340 is returned at line 672. The secret information308(a)-308(b) needed by App 1 302 is extracted from the registryinformation at line 674, and is retuned to App 1 302 at line 676.

FIG. 14 provides a list 520 of the DLLs and the corresponding API callsthat are to be hooked. Column 522 identifies by name the particular DLLsthat are to be hooked/replaced by the secret server snap-in function526. Column 524 identifies by name the particular function within theDLL (in column 522) that is to be replaced, i.e., hooked. Column 526identifies by name the actual function that will be called within thesecret server snap-in hook 304 to obtain the secret information308(a)-308(b) from the secret server 340.

FIG. 15 provides instructions 540 on configuration of the secret serversnap-in hook 304 for an application named sample. The configuration maybe separated into a local section 542 and a remote section 544.

In the local section 542, a local configuration provider determines thetype of interface that is being used to access the configuration thatcontains the secret information for the sample application. This will beused by the associated secret server snap-in hook 304.

The configuration provider may be file or registry. The sampleapplication may reference the configuration file or the registry for thesecret information 308 in the local storage 306. This is dependent uponthe application. In this case, the secret information 308 is in a file,and the file is located at c:\\sample\\config.json.

In the remote section 544, a remote configuration type determines whichsecret service interface should be used when obtaining the secretinformation 308(a)-308(b). The secret service interface, for example,may be an Azure Key Vault or a Hashi Corp Vault.

In this case, the Azure Key Vault is to be selected, and the secretinformation 308(a)-308(b) in the secret server 340 is located atsample.config.json path. The remote configuration connection containsthe information required by the secret service provider to establish aconnection. The secret names are the actual configuration names withinthe configuration file or registry as determined by the localconfiguration provider.

The above configuration includes enough information to accommodate basicas well as advanced operations. An advanced operation would providecapabilities for caching secrets, receiving notifications of secretupdates (e.g., for rotation purposes), as well as credentials foraccessing the secret server.

Although the secret server snap-in hook 304 provides for additionalflexibility, there are two scenarios for the in-hook algorithm: File andRegistry. In both cases, allowed list “white-list” or “allowed list” ofconfiguration paths (files in file scenario and specific secrets inregistry scenario) is defined.

In the first case, the File hook will get called upon each file opencall. When the hook is invoked it will be passed the full file path(e.g., “c:\sample\config.json”), and a simple lookup will be done withinthe snap-in configuration as defined above. If the configuration filecontains a match, then the secret server logic will be invoked for thefile open. In the simplest form, it means the entire contents of theconfiguration file will be read. This can be written to a secure hiddenfile for simplicity.

In the second case, the Registry hook will get called upon each RegistryQuery Value call. When the hook is invoked, similar to the file hook, itwill be passed the full registry path (e.g.,“HKLM\Software\Citrix\SampleApp\Secret1”), and a simple lookup will bedone within the snap-in configuration. If the configuration filecontains a match, then the secret server logic will be invoked for theregistry query value. In the simplest form, it means the individualsecret value will be read and returned. It could also be cached locallyin a secure store.

As part of the snap-in process, several assumptions may be made tosimplify the process. One assumption is that the secret server snap-inhook 304 will be running in a user context capable of accessing thelocal file and registry system. Another assumption is that thesecret-server snap-in hook 304 is configured with credentials able toaccess the given secret server 340.

If there is no caching initially, a more advanced solution involves thebuilt-in Windows credential manager (i.e., wallet) being used as acache. An in storage dictionary of secure strings could be used as acache. An event handler could be established to receive secret updatesand update the local cache to support automated secret rotation. Astartup task could communicate with the secret server 340 at boot timeto perform an initial read of all secrets being handled by the secretserver snap-in hook 304.

Referring now to FIG. 16 , a simplified flow diagram 700 involving thesecret server snap-in hook 304 will be discussed. This is a high levelprocess view and assumes that the secret server snap-in hook 304 is inplace. The simplified flow diagram 700 is meant to provide a logicalflow of the process without showing the added complexity of the modulesbeing hooked and redirections to the secret server 340.

The secret server snap-in hook 304 has a configuration file that definesthe name of the application and the property names that should beobtained from the secret server 340. When the application (e.g., App 1302) is started in Block 702, the driver 430 will inject the secretserver snap-in hook 304 into the application.

When the application 302 makes a request for the configuration file inBlock 704, the secret server snap-in hook 304 will intercept the calland perform a series of steps. In decision Block 706, a determination ismade if the call is from a process of interest (e.g., the secret serversnap-in hook 304 is in place). If no, the call will be forwarded to theoriginal configuration file reading code in Block 712. The value for theproperty obtained from the local storage 306 will be returned to Block704.

If yes, a determination is then made in decision Block 708 if theproperty of interest is to be obtained from the secret server 340. Ifthe property of interest is to be obtained from the secret server 340,the secret server 340 will be called in Block 710 and the value for theproperty obtained from the secret server 340 will be returned to Block704. If the property of interest is not to be obtained from the secretserver 340, the call will be forwarded to the original configurationfile reading code in Block 712. The value for the property obtained fromthe local storage 306 will be returned to Block 704.

Referring now to FIG. 17 , a flowchart 800 illustrating a method foroperating the computer system 300 will be discussed. From the start(Block 802), the method includes storing in memory in Block 804 anapplication 302.

The method further includes operating a processor coupled to the memoryto start the application in Block 806, and insert a secret-serversnap-in hook 304 into the application 302 during start-up. Thesecret-server snap-in hook 304 has instructions to access a secretserver 340 with secret information 308(a)-308(b) stored therein. Inresponse to a call being made for the secret information 308 in Block810, the secret-server hook 304 intercepts the call. The secretinformation 308(a)-308(b) in the secret server 340 is provided to theapplication 302 based on the intercepted call in Block 812. The methodends at Block 814.

As will be appreciated by one of skill in the art upon reading the abovedisclosure, various aspects described herein may be embodied as adevice, a method or a computer program product (e.g., a non-transitorycomputer-readable medium having computer executable instruction forperforming the noted operations or steps). Accordingly, those aspectsmay take the form of an entirely hardware embodiment, an entirelysoftware embodiment, or an embodiment combining software and hardwareaspects.

Furthermore, such aspects may take the form of a computer programproduct stored by one or more computer-readable storage media havingcomputer-readable program code, or instructions, embodied in or on thestorage media. Any suitable computer readable storage media may beutilized, including hard disks, CD-ROMs, optical storage devices,magnetic storage devices, and/or any combination thereof.

Many modifications and other embodiments will come to the mind of oneskilled in the art having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it isunderstood that the foregoing is not to be limited to the exampleembodiments, and that modifications and other embodiments are intendedto be included within the scope of the appended claims.

That which is claimed:
 1. A computer system comprising: a memoryconfigured to store an application; and a processor coupled to saidmemory and configured to perform the following: start the application,insert a secret-server hook into the application during start-up, withthe secret-server hook having instructions to access a secret serverwith secret information stored therein, and in response to a call beingmade by the application for the secret information, the secret-serverhook has further instructions to perform the following: intercept thecall, and provide the secret information in the secret server to theapplication based on the intercepted call.
 2. The computer systemaccording to claim 1 wherein after the call is made for the secretinformation, the secret-server hook has further instructions to redirectthe intercepted call to the secret server to retrieve the secretinformation from the secret server.
 3. The computer system according toclaim 1 wherein before the call is made for the secret information, thesecret-server hook has further instructions to retrieve and cache thesecret information from the secret server.
 4. The computer systemaccording to claim 3 wherein the secret information is cached using aprotective storage.
 5. The computer system according to claim 1 whereinthe call being made for the secret information is directed to aconfiguration file or registry that includes blank information insteadof the secret information initially stored therein, and afterinterception of the call, the secret-server hook has furtherinstructions to search and replace the blank information in theconfiguration file or registry with the secret information from thesecret server, and return an updated configuration file or registry tothe application.
 6. The computer system according to claim 1 wherein thecall being made for the secret information is directed to aconfiguration file or registry, wherein the secret server is configuredto store the same configuration file or registry, and after interceptionof the call, the secret-server hook has further instructions to returnthe configuration file or registry from the secret server to theapplication.
 7. The computer system according to claim 1 wherein thesecret information in the secret server is stored as at least one ofname value pairs, a single encoded string, and a format dependent on thesecret server.
 8. The computer system according to claim 1 wherein saidmemory and said processor are in a virtual machine.
 9. The computersystem according to claim 1 wherein the secret information is needed bythe application to access a resource external the computer system.
 10. Amethod comprising: storing in memory an application; and operating aprocessor coupled to the memory to perform the following: start theapplication, insert a secret-server hook into the application duringstart-up, with the secret-server hook having instructions to access asecret server with secret information stored therein, and in response toa call being made for the secret information, the secret-server hook hasfurther instructions to perform the following: intercept the call, andprovide the secret information in the secret server to the applicationbased on the intercepted call.
 11. The method according to claim 10wherein after the call is made to for the secret information, thesecret-server hook has further instructions to redirect the interceptedcall to the secret server to retrieve the secret information from thesecret server.
 12. The method according to claim 10 wherein before thecall is made for the secret information, the secret-server hook hasfurther instructions to retrieve and cache the secret information fromthe secret server.
 13. The method according to claim 12 wherein thesecret information is cached using a protective storage.
 14. The methodaccording to claim 10 wherein the call being made for the secretinformation is directed to a configuration file or registry thatincludes blank information instead of the secret information initiallystored therein, and after interception of the call, the secret-serverhook has further instructions to search and replace the blankinformation in the configuration file or registry with the secretinformation from the secret server, and return an updated configurationfile or registry to the application.
 15. The method according to claim10 wherein the call being made for the secret information is part of aconfiguration file or registry, wherein the secret server is configuredto store the same configuration file or registry, and after interceptionof the call, the secret-server hook has further instructions to returnthe configuration file or registry from the secret server to theapplication.
 16. A computing system comprising: a secret server withsecret information stored therein, with the secret information requiredby an application to access a resource; and a computer systemcomprising: a memory configured to store the application; and aprocessor coupled to said memory and configured to perform thefollowing: start the application, insert a secret-server hook into theapplication during start-up, with the secret-server hook havinginstructions to access said secret server for the secret informationstored therein, and in response to a call being made by the applicationfor the secret information, the secret-server hook has furtherinstructions to perform the following: intercept the call, and providethe secret information in said secret server to the application based onthe intercepted call.
 17. The computing system according to claim 16wherein after the call is made for the secret information, thesecret-server hook has further instructions to redirect the interceptedcall to said secret server to retrieve the secret information from saidsecret server.
 18. The computing system according to claim 16 whereinbefore the call is made for the secret information, the secret-serverhook has further instructions to retrieve and cache the secretinformation from said secret server.
 19. The computing system accordingto claim 16 wherein said memory and said processor are in a virtualmachine.
 20. The computing system according to claim 16 wherein thesecret information is needed by the application to access a resourceexternal the computer system.